As more and more businesses and organizations move toward networked-based services, performance modeling will become increasingly more important. Performance modeling refers to creating a computer model that emulates the performance of a computer system.
As those skilled in the art will appreciate, performance modeling can be used to predict and analyze the effect of various factors on the modeled system, these factors including changes to the input load, or to the configuration of hardware and/or software. Indeed, performance modeling has many benefits including performance debugging (identifying which, if any, system components are performing at unacceptable levels, and why they are underperforming), capacity planning (applying projected loads to the model to analyze what hardware or configurations would be needed to support the projected load), prospective analysis (the ability to test “what if” scenarios with respect to the system, its configuration, and its workload), and system “health” monitoring (determining whether the computer system is operating according to expected behaviors and levels).
While performance modeling provides tremendous benefits, currently, good performance modeling is difficult to obtain. More particularly, it is very difficult to accurately and adequately create a performance model for a typical system in all its complexity. As such, generating performance models have largely been the purview of consultants and others with specialized expertise in this arena. Even more, performance modeling is currently the product of laboratory, controlled environment analysis. As such, even the best performance models only approximate what actually occurs in the “live”, deployed and operating system.
There are several performance factors that are used to generate a performance model of a particular system, hereafter referred to as the subject system. FIG. 1 is a block diagram illustrating exemplary performance factors used to create a performance model of a subject system. These performance factors include: the physical topology 102 of the subject system, i.e., the hardware operating/supporting the subject system, including multiple computers, CPUs, network interface cards, disk drives, RAM, and the like; the logical topology 104 of the subject system mapping how the various discrete software components of the subject system are distributed on the physical topology 102; the system workload 106 of the subject system identifying the transactions to be performed on the subject system, as well as an estimation as to the frequency of these transactions; the transaction workflow 108 identifying the discrete actions carried out by each transaction; and the action costs 110 that identify costs associated with performing each discrete action, such as CPU time, communication bandwidth, disk storage space, memory usage, and the like.
Once established, these performance factors 102-110 are combined to generate a performance model 112 of the subject system. Using this performance model, a user can then create performance predictions 116 regarding the subject system. Even further, based on the performance predictions of the subject system, additional uses and analyses may be generated, including bottleneck analyses 118, system health reports 120, “what if” scenarios 122, capacity planning 124, and the like.
With regard to the performance factors, the physical topology 102, the logical topology 104, and the system workload 106 are generally viewed as dynamic factors, i.e., they are readily subject to modification such as by adding additional computers, memory, reducing the number of transactions performed, etc. However, the transaction workflow 108 and the action costs 110 are considered to be static factors 114 as this information does not readily change. In other words, while the speed of the CPU may increase, or communication bandwidth is improved, the discrete actions carried out by a single user transaction remain the same.
There are automated tools that can be used to determine the physical topology 102, logical topology 104, as well as estimate a system workload 106, even in a deployed system. However, in order to determine the static performance factors 114, particularly transaction workflow 108 and action costs 110, a consultant or expert with intimate knowledge of the various subject system components is needed, and uses a controlled, laboratory like environment, not a deployed system. Under these control conditions, and by repeated tests and analysis, using the expert knowledge of the consultant with regard to the components tested, the transaction workflow 108 and action costs 110 are derived. Of course, while this is very expensive and time consuming, those skilled in the art will also readily appreciate that many “things” occur within a deployed system that do not arise in a controlled, laboratory-like environment. Thus, even after expending substantial effort and resources to create a performance model of subject system, at best, current performance models are only an approximation of the deployed subject system.